DataPower FSH (FrontSide Handler) provide the Compression field.

From the InfoCenter:
http://pic.dhe.ibm.com/infocenter/wsdatap/v5r0m0/index.jsp?topic=%2Fcom.ibm.dp.xg.doc%2Fmultiprotocolgatewaydevelopersguide.xg4594.htm

11. Set Compression to enable or disable the negotiation of GZIP compression.

Important is the word "negotiation" here.

If you are using a browser to access a DataPower service, then your browser and DataPower do the negotiation for you.
Nothing needs to be done by you.

So what if using "curl" to access a DataPower service?

From "curl" manpage:

       --compressed
              (HTTP) Request a compressed response using one of the algorithms
              libcurl supports, and return the uncompressed document.  If this
              option is used and the server  sends  an  unsupported  encoding,
              curl will report an error.

You can check whether "your curl" does support gzip compression by executing "curl -V".

If you find "libz" amount the "Features" then it can.

Again, "--compressed" does a negotiation, no guarantee that both sides (curl/DataPower) will agree on compression.

So how can you "see" whether compression was used?

Yes, a packet capture will allow you to see this.
But there is a simpler method, use "curl -v" (for "verbose" output).
If the HTTP response from DataPower contain "Content-Encoding: gzip" header entry, then response was returned compressed.

I just turned Compression on on coproc2 service FSH and did send ab.xml (<a>1<b>2</b>3</a>) with double.xsl stylesheet:

$ coproc2 double.xsl ab.xml http://dp1-l3:2223 -v --compressed ;echo
* About to connect() to dp1-l3 port 2223 (#0)
*   Trying 9.152.93.8... connected
* Connected to dp1-l3 (9.152.93.8) port 2223 (#0)
> POST / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: dp1-l3:2223
> Accept: */*
> Accept-Encoding: deflate, gzip
> xsl: H4sICCV0GU8AA2RvdWJsZS54c2wAjZCxbsQgEER7fwWih83pKltwX5DuUlyL8Dq2BAbBXrD/PuBLckmXcnfezKxWbdkNmXaHeUYk9oEpL2HV/CRfeMfY5t2ahwppPhPFAaCUIstZhvQOp77v4XZ9hbdk1jyF5J+WMf5xjIZMDAWTtMEDboRr68nN8DMJdOhxJRETTsuGWfMx8u5SGdXuDHeKd2LBLyRqixjROpMMHQfvmDmDxjL2bSD00RlC5g3ZWXPgh65q0AM8KBviLsLEcq23pLnk8A9VwVeKgt9VbdM9Vs+3XrpPG5mOnmgBAAA=
> Content-Length: 18
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< X-Backside-Transport: FAIL FAIL
< Connection: Keep-Alive
< Content-Encoding: gzip
< Transfer-Encoding: chunked
< Content-Type: text/xml
<
* Connection #0 to host dp1-l3 left intact
* Closing connection #0
<out><a>1<b>2</b>3</a><a>1<b>2</b>3</a></out>
$

As you can see ("< Content-Encoding: gzip") compression happened.

And for those who really want to see what got returned, here is "Follow TCP Stream" output from packet capture in Wireshark:

Hermann_{<myXsltBlog/> <myXsltTweets/> <myCE/>}